Exception access violation on "release" statement

Hi!

For one of our projects we get repeated reports about an exception error that occurs regularly (they say in ca. 25% of their runs).

(the usual -R-E- DXL: <myfile.inc:124> An unexpected error has occurred: doors.exe caused an EXCEPTION_ACCESS_VIOLATION in module doors.exe at ..., followed by a diagnostic log window

The relevant code is

// define button on a dialog
dOkButton = button( wMYBox, 'sometext', okBtnCB, true, iButtonWidth)

// callback function of OK Button
void okBtnCB( DBE dCallerDBE ) {
  DB dParentWin = getParent( dCallerDBE )
  // do a lot of stuff including opening modules, giving info boxes, but don't close the dialog
  closeCB( dParentWin )

// callback of close
void closeCB( DB dCallerWin ) {
  release dCallerWin
  hide dCallerWin
}
 

The error occurs in the line "release dCallerWin".

I could not reproduce this problem, so I think it might have something to do with not windows ressources left on the computer when DOORS tries to release a dialog, perhaps it is already released internally?!?.

Is there any way to determine whether a "release" of a DB can safely be done?

Anyone any idea?

Thanks and best regards
Mike

Re: Exception access violation on "release" statement
llandale - Wed Aug 27 15:47:37 EDT 2014

Three problems I see with your "blocked" dialog.

[1] Any structure other than the following is asking for trouble.

• The close callback should only "release(DB)" the dialog; although it could do non-dialog stuff as well.
• the "hide(DB)" and "destroy(DB)", if any, should be right after the "block(DB)" statement.

[2] I sure hope you code has your code in reverse order than you posted.  closeCB first, okBtnCB second, "button" command last.  If not, then I'm guessing you have some other "closeCB" defined somewhere near the top of your code, and okBtnCB is either calling the wrong function or the interpreter is getting lost in its references.

[3] Something doesn't feel right about "releasing" the input DB parameter.  Maybe that's just me.  If I'm right, then you should "release(wMyBox)".  I have some nagging memories of the "call by value" required in the callback (not "DB &dCallerWin"), when the system is trying to nullify the dialog handle.

Re: Exception access violation on "release" statement
Mike.Scharnow - Wed Aug 27 17:03:01 EDT 2014

thanks for your hints. with [2] you are of course correct.

You are right, the dialog is shown using "block", not "show". This was the important hint for me. It seems that the script has been written with two alternatives in mind, using either block or show depending on the situation (whatever the reason was). Now only the "block" statement is ever called, which is followed by the "release" and "destroy", but in the closeCB there is also a "release". So, "release" is called twice, which might be the reason for the problem.

What I had in the script was

closeCB():
release
hide


main():
block
release
destroy

I now changed it to:

closeCB():
release


main():
block
hide
destroy

Let's see if the users continue to complain :)

If it does not help, I will consider [3], but that would be a bigger change, as several dialogs in our application have been written that way.

thanks very much
Mike

Re: Exception access violation on "release" statement
llandale - Thu Aug 28 16:25:40 EDT 2014

If your fix works, then you should have been getting the error at the "release" line following the "block".  Seems like the 2nd "release" won't work on a "hidden" dialog.

If you have show/block logic, your close callback will need to know; "destroy(db)" when "shown" or "release(db)" when blocked.  Instead of that I've just put different close callbacks on the dialog; so the callback only works on one type.

• create dialog
• if (I want to block)
• {  close(db, true, clbkClose_Block)
•    block(db)
• }
• else
• {  close(db, true, clbkClose_Show)
•     show(db)
• }

-Louie

I write a lot of scripts, but its rare there is more than one dialog, and in any event the number is always small so I can always have specific callbacks unique for specific "buttons" and "apply"s; meaning the callback already "knows" the dialog or element it is supposed to deal with.  So realistically I rarely look at the callback parameter  void clbkClose(DB dbXX); I ignore dbXX.  I have little such experience, and do recall having some trouble with it; certainly the "destroy" won't work right in such a callback since it sets the DB to null, but the calling clbk has it passed in by value.